J 



Europaischds Patentamt 
European Patent Office 
OfRce europ^an des brevets 




@ Publication number : 0 597 316 A2 



EUROPEAN PATENT APPUCATION 



@ Application number: 93117333.0 
(g) Date of filing : 26.10.93 



Int Cl.^ G06F9/44 



Priority: 09.1192 US 972779 



fiS) Date of publication of application : 
1&05.94 Bulletin 94/20 



^ Designated Contracting States : 
^ AT CH DE FR GB IT U NL SE 



@ Applicant : VIRTUAL PROTOTYPES, INC. 
5252 De Maisonneuve West Suite 318 
Montreal, Quebec MA 3S5 (CA) 



(g) Inventor : JosephiEugene R. 
4692 Roeiyn Street 
Montreal(Quebec) (CA) 
Inventor : Trachtman,Michael 
542 California Sbreet 
Newton,Massachuselte 02160 (US) 



(g) Representative : ZeMer & DIcket 

PatontanwMlto European Patent Attonneys 
Postfeeh 26 02 51 
D^S9 Munchen (DE) 



(g) Computer simulation eyetem and mettiod f6r specifying the behavior of graphical operator 



Sh A computer simulator system allows the user to specify prototype reaction to events in a pictonal 
manner using a visual object environment A spreadsheet like Slate Table and a visual object collection 
coincide on a common graphical display. The State Table Is filled in by pointing to lists of events or 
actions associated with the different objects. The contents of these lists are dependent on the object 
dass. Event or action descriptions are transported into the respective cells of the State Table in the fonm 
of descriptive strings of text This text desaibes the event or action, and the event sourcse, or action 
destination. Entries in the State Table define the operation of the simulation and are executed direcUy 
by an interpreter or are compiled to generate a program of instnjctions for perfbnming the simulation. 
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BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The invention relates to a system for and method of interactive, graphical computer simulation and, in par- 
ticular, to a system and method for providing user programming of interactive, graphic and dynamic applica- 
tions through pictorial means. 

2. Description of the Related Art 

Digital computers have long been used to perform complicated and tedious numeric calculations and data 
processing. With increased processing speed and memory capability, the roles of digital computers have ex- 
panded to Include real-time simulations of mechanical, electrical, and other complex systems. 

At first software for performing digital computer simulation required advanced progranming skills, the 
programmer coding the in^ructions in a low level language such as assembly language or machine code. This 
was done to provide the necessary Interface between operator inputs and graphic objects displayed on an 
output device such as a graphic display or video monitor. With the development of high level languages, it be- 
came feasible to construct program generator systems to assist In the development of programs for performing 
the simulation. An example of such asinujlatlon system is the Virtual Applications Prototyping System (VAPS) 
20 commercially available from the assignee of the subject application. The system Is disclosed in system doc- 
umentation publications including "VAPS: Conceptional Overview"; -VAPS: Reference Guide": 'VAPS: Pro- 
giammers's Guide"; and "VAPS: Installation Guide and Options" aD by Virtual Prototypes (1991) and incorpo- 
rated herein by reference. 

The VAPS system Is a tool for designing, testing, and implementing user interfaces. A prototype or "mod- 
25 eled" system is the result of the design work done with design tools constituting the VAPS simulation system. 
A user interface Is a part of hardware and software that provides for human control and feedback. For a soft- 
ware program, human control and feedback can include graphs, menus and prompts. For a product such as 
a radio, the interlace can Include scales, dials, and knobs. Thus, the user interface is a bridge for a human to 
access an application. 

so The resultant vlrtualized "prototype " system Is a graphics slmulatkin of a control and display mechanism 
equivalent In appearance, form, f unctkinality. behavior, animat ton, etc. to the modeled system. The virtualized 
prototype representation is also applicable to the generation of source doe implementing equivalent functton- 
ality on a target system. Thus, as used herein, the prototype system Is functtonally equivalent to a modeled 
system. However, while the virtualized system is termed to be a prototype, it is not limited to initial system 

35 devetopment but may constitute the final terget system. 

The VAPS system supports devetopment and testing of dynamk:. graphical front ends for existing appli- 
cations and maintenance of the user Interface by allowing changes to be made visually. VAPS conteins four 
primary modules or subsystems: (I) an Object Editor, (ii) an Integration Editor. (iiD a Log»c Editor, and (iv) a 
Runtime Environment 

40 Briefly, the Object Editor is used by the operator to buikJ the visual interface to the appllcatton. Using the 

Object Editor, the user draws objects that make up the graphteal Interface for the prototype. The objects are 
then assigned runtime behavtor. The user employs the integratton Editor to define and build date connect tons 
or routes between the visual interface and an Application program date. That Is. after the display image Is pro- 
duced using the Object Editor, the Integration Editor connects Objects to each other, to date sinks, and to date 

45 sources. At the system level, date oonnecttons can be made by defining global prototype/applications system 
variables. 

The Logic Editor allows the user to define and specify how events are to be managed. Using the Logic 
Editor, the user can devetop a logk: control program to manage events from the user interface. Finally, the 
Runtime Environment animates the prototype and altows the user to interact with the prototype. 
50 In the VAPS system, the Object Editor is a window-based, graphical system used to draw and describe 
objeclsthatmakeupaman-machlne Interface (MMI.) The VAPS MlMIs are collections of objects having a visual 
representation created by the user and a functional behavtar assigned to the graphical representetton. 

The Object Editor allows the user to build the t uncttonal behavtoi* exhibited l>y complex objects or dls^ 
plays In runtime by specifying a list of object descriptions. The functional behavior of an object refers to how 
56 the graphic representetion of an object responds to date receded and generated by the prototype. 

The objectdescripttons define two types of objects: Input and output objects. In general, input objects react 
to user control to supply date to the simulation program representing the "prototype" or "modeled" system. 
Output objects react to date generated by the input objects, as well as to Internal and external date sources 
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of data. Output objects reflect the data by changing appearance in accordance with the predefined functional 
behavior of the respecth^e object type. Thus, an output object such as a virtual nrieter might be graphically rep- 
resented by a graduated scale and a pointer, the position of the pointer relative to the scale being responsh^e 
to predefined data generated by the prototype system. 

5 Input objects accept user inputs and pass data to the system for processing. Typical classes of virtual input 

objects include buttons, locators, menus, knobs, switches, event labels, input fields, etc Virtual Input objects 
can be defined to be responsive to a corresponding physical input device, such as a mouse, keyboard, touch 
screen vahiator. or a custom device. 

Once the application program has processed the information, the results are displayed on a video monitor 

10 screen using output objects. Typkal classes of output objects indude dials, lights, plots, cursors, bar charts, 
tapes, output fields, eto. Thus, output objects are different representations enabling viewing of data generated 
by the application. When the data changes, the output objects are dynamksally modified to reflect the new 
value. 

The functtenallty. I.e. behavior, of objects Is defined using property sheets. The contents of a property 
95 sheet are dependent on the dass of the object described by the property sheet For example, a property sheet 
for a dial dass (i.e.. rotational) object defines the name of the object display position origin, moving part, center 
of rotation, position pointer, initial pointer position, direction of motion, type of motton, and mininnum and max- 
imum positions and corresponding values. 

As described, the Object Editor is used to draw the visual portion of the simulated prototype and define 
20 the functionality of objects. The Integration Editor Subsystem animates the objects by providing a dato con- 
nectton to the application data. Connections with the Integratton Editor are nrtade by spedf ying a correspon- 
dence or mapping between an object and a dato source or dato sink. 

For example, if a "Dial" type of output object represents the temperature in a boiler, the temperature can 
be changed by an external source. The correspondence between the temperature and the Dial reading is made 
25 in the I ntegratton Editor. Similarly, an input objed that is created and f undfanally defined in the Object Editor 
is connected via globally defined dato to provide user Input to the application progranv 

Integration produces a data connection allowing virtual input objeds to transmit dato and output objects 
to receive data. TTie dato controls the functional behavior of a virtual objed or alters the attributes of a virtual 
ot^ect, such as a displayed position or shape of the virtual object. 
30 Using the Integration Editor, dato connedions to and from a virtual objed are made through a dato chan- 
nel. Dato connecttons between vntual objeds can be made dlredly from one virtual objed to a series of other 
virtual objeds. This is accomplished by storing the variable information from an input virtual objed In a mem- 
ory location, referred to as a data channel, and conneding the one or mote output virtual objeds to the same 
memory location to read the updated variable. 
35 Dato generated by dato generators of the prototype interface are connected through dired point-and-dick 
connedions. Thus, an output virtual objeds can directly reoeh/e dato generated by the MMI. As used herein, 
"peint-and-dlck" and "dickon" refer to designation of an element or virtual objed displayed on a vkteo monitor. 
This is typically accomplished using a mouse, joystick, touch screen or other graphic input device to positk>n 
a cursor displayed on the monitor (i.e., point) and adivating a momentary switeh to designate the element or 
40 virtual object at the cursor position (i.e., dick or dick-on) for further processing. 

External user-defined applicatk)n programs can also provide date. The memory locattons for input and 
output virtual objeds can be configured to transfer data to and from an external user appllcatton program, 
with the application program reading and writing to predefined dato channels. 

Finally, real devices can be directly integrated Into the prototype with the interface. Such real devtees In- 
45 elude input devices such as sensors, joysticks, trackballs, and keyboards. 

The Integration Editor maps user Input and output informatfon to dato locations without regard to where 
the date originates. A pictorial interface maps dato to provide a dired outlet to a virtual objed called a plug. 
All virtual objeds have such an associated plug. i.e., a labeled date location accessible under program control, 
to make the date available to virtual objeds and applications programs. In comparison with having to program 
so memory connedions through a progrenuning language, mapping using the Integration Editor allows the user 
to define how the virtual objeds of the prototype are to oommuntoate with each other by passing date bade 
and forth using plugs. 

Each mapping variable is defined by making a pictorial connedton between the plug and the dato source 
or sink associated with a virtual object Therefore, when a virtual input objeds of a prototype are conneded 
65 to other data sources or sinks, only the informatran mapping needs to be changed, not the indivklual virtual 
objed definition. 

Colledors are used to define required combinatwnal Boolean or mathematical f und Ions for appHcatton 
programs requiring the combination of several input sources to drive a single output virtual object Collectors 
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can also be used to determine a critical state by comparing an input value with a threshold value. 

Data connections are also used to inteiiaoe Input objects of a prototype with an external application pro- 
gram. For example, interactive application programs may require control and display data interfaces to a pro- 
totype. The interlace providee data communications between virtual objects and extemaDy provided data. The 
5 prototyping development system also defines and provides communications with databases using connecting 
variables and remote or local communications. 

The Logic Editor is used to model the prototype system by defining prototype system states and events. 
The system uses a Rnite State Machine (FSM) concept as the framework for MMI dedsiorvlogic development 
This allows the prototype system to manage events In a context that takes system history into account and 
10 supports a fine-grained modelling system fundbnality. thereby enhancing system reliability. 

Prototype system behavioral modelling with the FSM concept produces a model containing af inite nuntber 
of states. Each prototype state is entered and exited based on the occurrence of a virtual event Events can 
be user or applicatton generated. 

To handle FSM modelling, the Logic Editor uses an Augmented TransRion Network (ATN) language. The 

19 ATN language provides a structure for recognizing events and servicing transitions between prototype system 
states. Transittons are serviced by invoking routines and then transttionlng or moving to the next state. 

The Logic Editor is used to produce an ATN program and define prototype system operatton. The ATN lan- 
guage has two basic constructs, the STATE and the EVENT. These constructs map to the nodes and links 
of a oonventk>nal state diagram to define prototype Interface decisions, i.e^ provide logic control and actton 

20 routines. The general structure of an ATN program is as follows: 

STATE start_state 

{ initialize the state's parameters if required } 

25 ( EVENT eventl) (condition) { response > 

-> NEXT_STATE 

( EVENT event2) (condition) { response } 

-> NEXT STATE 
30 - 

etc. 

When a virtual eventoccurs, the prototype system is in a particular predefined stete. The prototype system 
checksthat the event that has occurred matches one of the transitions (i.e., an event and a condition) declared 
35 in that state. If the event is matohed and the conditton is true, Le.. valid and passed, the prototype system 
executes the response by executing a number of routines. The prototype system then proceeds to the next 
state, awaiting other virtual events. Thus, the ATN code is used to define decision making of the prototype 
system. 

Input generated events can be received by the ATN program and output virtual objects can be addressed 
40 by action routines invoked by the ATN program. The MMI can respond to virtual and real events originating 
from many sources, including date entry, selection, discrete device input (such as a button, switch, input field, 
etc.), a continuous discrete devk» input reaching an increment (such as a potentiometer, knob or locator), time- 
out, periodic event. variaWe value crossing a threshold, votes input or a user-definable event. 

In ofderto service events, action routines are dispatched, I.e., Invoked to service the event. The prototype 
45 development system makes libraries of action routines available to fulfill a variety of functions Including per- 
forming specific object operations, manipulating graphteal images and virtual objecte on a virtual CRT screen, 
altering line types, patterns, fonts, and colors under program control, performing geonwtrk transformations 
under program control, writing to output fields and reading from Input fields, type checking for strings, com- 
municating wHh an external simulation via Ethernet or other specialized buses, and remapping object plugs. 
so Once the functionality of the user interface is completed using the Object Editor, Integration Editor, and 
Logic Editor, the dynamics of the prototype are displayed at runtime in the Runtime Environment and the user 
is allowed to interact with the prototype through various real and simulated input devices. The Runtime En- 
vironments permits a user to evaluate the prototype and operation of the final MMI. 

Using such a prototype development system, an essential part In the programming the human-computer 
65 interfaces for the prototype is to specify the behavior of the interface to virtual events. Such events may be 
generated by input devices (buttons, locators and triggers, keyboards, selects, f undfon keys, touch screens, 
pictoriel touch panels, votee interfaces) as well as by atimeout, a message from another system or a variable 
crossing a threshold value. 
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It is convenient to use a Rnite State Machine (FSM) paradigm to respond to virtual events. Use of a FSM 
is suited to addressing sequencing problems often found in operator interfaces, and allows structuring of the 
control logic in an orderly, regular fashion. 

When an FSM is used, virtual events are processed In the context of a history of prior events and system 
5 states. A combination lock provides a good example of events interpreted In a context of prior events. Only 
the correct sequence will open the lock. 

In another example, the pitot command landing gear up* should only be serviced In the state "Weight- 
of^wheels" and not in the state ■Wetght-on-wheels', In a FSM. the system is deemed to be in one of a finite 
number of states. When input arrives, a transHkm is executed from the present state to the next state. The 
10 next state depends solely on the input and the present state. The output also depends solely on the input and 
the previous state. When applying the FSM model to operator Intertaces, FSM input Is made up of discrete 
events and FSM output is the dispatch of a series of subroutines or setting of plug variables. If a logical con- 
dition is tested before undertaking the transitfon. the FSM is an ATN. 

ATMs or FSMs can ba programmed with a text editor, by completing entries in a taWe or with a pictorial 
15 editor. However, textual completton of the table requires an in-depth knowledge of the syntax and structure 
of the ATN or FSM. 

Accordingly, a need exists for an improved method and structure for defining the operation of a simulatton 
system without requiring a knowledge of programming, FSM or ATN languages. 

A further need exists for a method of. and structure for, defining a State Table using a grBphlcal input and 
20 pull down, context sensitive menus. 

A need further exists for a system to visually relate input and output virtual objects using a grephto input 

device. 

A need further exists for a system which presents a user selectton of valid relatkjnships between virtual 
objects and available states. 
25 A need further exists for a tool to specify a desired behavtor using an graphic input device such as a mouse 
to point to. and designate, virtual objects which are part of the behavior and by designating desired virtual 
object behavtor from menus. 



Summary of the Invention 

30 

The invention Is directed to a context responsive menu driven prototype development and simulatton sys- 
tem responsive to a graphic input devtee for defining relattonships between and among prototype virtual ob- 
jects displayed on a graphics display such as a video monitor. The relationships are defined by user completion 
of a Stete Table defining prototype system states, virtual events or triggers, virtual acttons, and next states. 

35 Parametere are Input to the table using a combination of Images of objects appearing on t he computer screen 
together with graphically designated menu selections and alphanumeric keyboard entries. Upon completton 
of the State Table, the parameters are translated Into an Augmented Transition Network (ATN) or similar Ian* 
guage for execution on a target platform running the simulatton (i.e., workstatton. personal computer, nwin 
frame, etc.). Thus, the prototype development and simulation system and method according to the invention 

40 directs the user to relevant valid choices defining relattonships between virtual objects; displays and stores 
the relattonships, actions, events, and responses as a spreadsheet-like Stete TaWe; and translates the State 
Table into a compilable program or executabte language to be run on a target platform (e.g. computer) system. 

Accofding to the Invention, prototype system performance is defined using a graphical input devfce to des- 
ignate virtual objects and define relattonships between and among the selected virtual objects. Stete Tables 

45 in the form of spreadsheets are completed by Interacting with the image of an operator Interface composed 
of virtual objects, and deriving virtual events or acttons by clicking on the appropriate virtual objects. 

Messages sent by a virtual object, or methods executed by It, can be arranged in a list (e.g., in a pufldown 
menu) and Imported into the spreadsheet. For example, the event T*«ht XY2 is turned OFP would be gen- 
erated by clicking on the Image of the object light XY2, and extracting the event Turn OFF" from a pop-up 

so menus. Actions Impacting virtual objects are specified in a similar manner 

In conjuncttan with the prior prototyping systems described, whteb provide a graphfcal design environment 
for virtual object appearance, virtual object behavtor and virtual object interfaces, the inventton closes the loop 
for allowing full pictorial prxjgramming In the domain of dynamic, graphical operator interfaces. Pictorial pro- 
gramming allows computer users who do not have a traditional programming backgrourid to carry out tasks 

55 that normally require programming knowledge, thereby expanding access to computer simulations. 

The invention is further directed to a visual method of, and system for. programming Interactive, graphical 
applicattons on a computer system whtoh includes a graphical display and input devices, such as a mouse and 
a Iceyboard. The method Is particularly well suited to programming graphical, dynamic, Interaclh/e operator 
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interfaces. Dynamic operator Interfaces include applications with a graphical output which changes to reflect 

the values of data represented by virtual objects. 

The visual application is made up of virtual objects, which have both a graphical representation and a be- 
havioral model. The graphical representatton of a virtual object is defines using a graphics editor, or otherwise 
5 imported into the prototype system. A behavioral model Is specified by a Property Sheet that maps a behavtoral 

model for a virtual object to the visual representation. The mapping Is specified by pointing to features of the 

virtual object, such as line of motion or center 6i rotation, or typing-in values. 

The behavioral model is used to animate the virtual object in a manner consistent with the dass of object. 

For example, a 'Dial* type of virtual object me be predefined to nArte while a "Scale" type virtual object trans- 
10 lates, and a multi-state "Ughf type virtual object assumes one of several graphical representations to simulate 

a physical light. 

Virtual objects are connected to, or associated with, data values so as to animate the objects in response 
to the data. As the data changes, the virtual objects are redravwi to reflect the changed data value. This data 
can be generated by physical input ^vices. other virtual objects, software programs residing on the same or 
15 another computer, etc. 

The subject computer prototype development and simulation system allows the user to specify the reac- 
tion to events in a pictorial manner, in a visual object environment. For this purpose, a spreadsheet like State 
Table and the visual object collection coincide on the same graphical display. TTie State Table is filled in by 
pointing to lists of virtual events or actions associated wHh the different virtual ot>jects. The contents of these 
20 lists are dependent on the virtual object dass. Event or action descriptions are entered into the respective 
cells of the Stale Table, in the form of descriptive strings of text This text describes the events or actions, 
and the event sources, or action destinations. 

The State Table allows the user to specify prototype slate names, logical conditions, and the nntne of Ihe 
next prototype state for processing the next virtual event, thus i mplementing an ATN control paradigm of the 
25 user interface. This information is supplied by a user employing an alphanumeric keyboard, selecting from lists, 
or copying parameters from other cells of the spreadsheet State Table. Other control paradigms can be im- 
plemented using the same method, such as FSM, Rule based systems, or Petri Nets. The data stored in the 
State Table is used to automatically derive the control program for the prototype. 

Furthermore, In conjunction with the information stored in the virtual objects, a complete source code 
30 program can be generated. Tlie source code program, when compiled, linked, and executed in the presence 
of appropriate data, produces the same visual appearance, animation behavior and interaction behavior to oc- 
cur on a host computer system as on the original prototype development platform. 

The Invention includes a Slate Table Editor as an interactive module for specifying the behavior of a pro- 
totype using, for example, the commercially available Virtual Applications Prototyping System (VAPS). The 
35 Stale Table Editor or definition module friterface Is similar to a spreadsheet paradigm. In that the behavior of 
a prototype. Le., responses of virtual objects to data, events, and other virtual objects, is defined by completing 
a two-dimensional table, using a modern point, dick and type interface. 

The State Table Editor replaces the Logte Editor of VAPS to define reiatkmships between and anrwng vir- 
tual objects, events, states and acttons. The State Table Editor is compatible wtth various simulatton and pro- 
40 totyping systems. Thus. Augmented Transitran Network (ATN) language programs previously written using a 
Logic Editor are usable in the subject prototype development and simuiatton system. In addrtion, ATN programs 
can be converted Into Stale Tables and State Tables can be converted into ATN progranrts. 

The State Table Editor allows the user to specify the behavtor of a simulator prototype using a spreadsheet 
like interface. This spreadsheet Is used to specify the desired behavtor m terms of behavioral rules. Each be- 
45 havtoral rule is called a "Reaction". A read Ion specifies how the prototype should respond to a specified event. 
In its simplest form, a State Table specif teatlon for a prototype consists of a ooQection of Reaction Rules. 
This collectton of rules is called a Reaction Table. More sophisticated prototypes can contain more than one 
rule set. Each rule set is called a state. 

The Stato Table Editor has a -Point and Cifck" interface allowing the user to complete the State Table by 
so citeking on the prototype elements, Le.. designating a virtual object by manipulation of a graphics cursor using 
a graphic Input device such as a mouse. Then, using the mouse and/or a data entry device such as a keyboard, 
the user fills in the State Table to specify the desired behavior of the virtual object 

The State Table Editor package includes context sensitive menus and winctows to enable an inexperienced 
user to define prototype behavior. It allows the expert user to describe even complex behavkir, by provkling 
S5 access to an entire computer programming language such as "C or ADA. 

For example. If the user is specifying the behavior of a virtual object, then the State Table editor displays 
or "pops-up" a window whfch enumerates all the f undtens whteh can be performed by that virtual object 
If the virtual object is an input object Ihen alt the input events which that virtual objed can produce Is 
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shown in a menu. If the virtual object is an output object, then afl the functions which can control the virtual 
object is displayed. Once the appropriate event or function is chosen, a secowJ pop-up window allows the user 
to fin In the details/parameters of the virtual object Default values are nominally provided. If the parameter 
can have only a predefined set of allowaWe values, then these values are also displayed in a pop-up menu. 

5 The State Table Editor converts the sequence of key dicfcs and typed values into the appropriate textual 

syntax The textual syntax describing an event is the ATN syntax for finite state machines (FSM). Actions are 
described in a programming language such as "C". 

The State Table Editor provides a front end to the ATN capability of the prototype development system. 
The State Table defined by the user Is translated into an ATN program wWdi is compiled and used to drive 

to the target prototype system at runtime. 

The State Table Editor aflows a user who has IHtle or no proflramming experience to specify the desired 
behavior of a prototype by using a mouse to point to the virtual objects ¥irhich are part of the behavior, and by 
choosing the desired behavior from context sensitive menus. 

The foregoing and other objects, features, aspects and advantages of the invention wiD beconie more ap- 

15 parent from the following detailed description of the present Invention when taken In conjunction with the ac- 
companying drawings. 

Brief Descrlptfon of Drawings 

20 Rgure 1 is a block diagram of a processor platform according to the invention; 
Figure 2 is a blank state transition table; 
Rgure 3 is a display used to define a reaction rule; 

Rgure 4 is a display used to define a reaction table tor an Input virtual object; 
Rgure 5 is a State Table implementing the reactions rules specified in the State Table of figure 4; 
25 Rgure 6 is a State Table defining the operation of the depicted vWual objects; 
Rgure 7 is a chart of reaction trigger sources; 

Rgure 8 is a State Table defining using a FIRSTJHME trigger to define prototype responses; 
Figure 9 Is a display deptoling a State Table using an INITIALLY trigger to define prototype responses and 
a simulatfon virtual object; 
30 Figure 1 0 is a State Table including an IMMEDIATE event; 

Figure 11 Is a prototype modified to include two virtual control knot^s; 

Figure 1 2 is a flow chart depicting four phases of using the Slate Table Editor according to the inventton; 

Figure 13 is a saeen display according to the invention; 

Figure 14 depicts the display format of a Parameters Property Sheet; 
35 Figure 15 depicts the display format of another Parameters Property Sheet; 

Figure 16 depicts the display format of Parameter Value Windows; 

Figure 17 Is a flow chart of State Table Ceil selectfon according to the invention; 

Figures 18^20 are flow charts of State Table CeB configuration performed according to the invention; 

Figure 21 is a teble or EVENTS for two example classes of objects. 
40 Figure 22 Is a table of EVENTS not requiring specification of an ot^ecL 

Figure 23 is a teble or ACTIONS for two example classes of objects. 

Figure 24 is a table of ACTIONS not requiring specification of an object. 

Figure 25 is a flow chart of system operation in a relevant choice mode of operation; 

Rgure 26 is a flow chart depicting determination of default parameter valine according to the invention; 
45 Figure 27 Is a flow chart depicting system operation In response to a user parameter selection; 

Figure 28 is a flow chart depicting system operation In response to a user parameter value assignment 

selection; 

Figure 29 b a graphic image of a simulation display; and 
Figure 30 is a contpleted stete transit ion teUa. 

50 

Best Mode for Carrying out the Invention • 

A computer platform for the development and simulatton of a prototype is depicted In Figure 1. Acentral 
Processor 1 02 is connected to a Math Coprocessor 104 for executing arithmetic and logical operations respon- 
55 sive to a program of instructions stored in Random Access Memory 106. The program of Instructions includes 
an operating system such as Unix, software components of the prototype development system including (i) 
an Object Editor. (II) an Integration Editor, (iii) a State Table Editor, and (iv) a Runtime Environment module, 
and date ^aneiated by each to define the prototype. The Runtime Environment module also supports execu- 
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lion of a simulation of the prototype in response to prototype tiehavior specified by a State Table defined by 
the State TaWe Ecfitor. 

To speed memory access, the platform includes a Cache Memory Conlroiler 108 and Cache Memory 110 
for storing frequently used instructions and data. Mass system storage is provided by Disk Storage 112 and 
Disk Controller 114. Central Processor 102 can access Disk Storage 112 through Disk Controller 114 either 
via Input/Output Processor 116 or over Data/Instruction Bus 118 under the control of Bus Controller 120. In- 
put/Output Processor 116 also receives and formats data from Keyboard 122 and Graphics Input Device 124 
via Graphtes Input Interface 126, and Touch Panel 12B. Graphics Input Device 124 may include a mouse, joy- 
stick, light pen, digitizing tablet tradcball. keypad, or other device for positioning a vWeo cursor. 

The resultant prototype simulation is generated by Graphics Processor 130 under the control of Central 
Processor 102. Graphics Processor 130 generates alphanumeric and primitive graphic image data either under 
direct control of Central Processor 102 or in response to lists of instructtons or vectors stored in Random Ac- 
cess Memory 106. The image data Is stored as a bit mapped in«ge in Image Memory 132 and displayed by 
Video Monitor 134. 

The computer platform also Includes an External System Interface 1 36 for exchanging data with another 
computer system. Speech recognftion is supported by Speech Recognition Processor 138 whksh receives 
speech sounds at microphone 140. Interprets the sounds and provides a corresponding ASCII output string 
to Input/Output Processor 116. Finally, synchronous type operations of the computer platform are synchron- 
ized by System Clock 142 whteh also provWes periodic Interrupts signals at predetermined intervals set under 
} software control. ^ 

Referring to F^ure 2. the State Table is a two dimensional table with fbur columns and an unlimited number 

of rows. The four columns are: 
1- State 

2* Event or Trigger 
5 3 -Action 

4 - Next State 

A Stete Table represents the behavior of a prototype simulation as a collection of Reactkm Tables. The 
present Invenlton provides a method of. and apparatus for. filling in the stete teble of Figure 2 by controlling 
virtual objects on Video Monitor 134 in response to user Input signals derived from any or all of Keyboard 122, 
0 Graphic Input Device 124 or Touch Panel 128. Context driven windows are displayed on Video Monitor 1 34 In 
response to user designation of cells of the stete teble to be completed, the windows providing lists of valid 
teble entries for the selected cells. 

A reaction rule specifies how the prototype should respond to events. The Prototype must respond to a 
user operating real input devices in the which affect virtual input objects of the prototype. Using Keyboard 
s 122, Graphics Input Device 124 end Touch Panel 128, the user may push a virtual button, rotate a virtual knob 
or sIMe a virtual potentiometer graphically represented on Video Monitor 134. The simulator system responds 
to the Inputs by affecting the output virtual objects of the prototype as displayed on Video Monitor 1 34. 

For example, referring to Fig. 3, in response to the user activating a joystick or mouse of Graphic Input 
Device 124 or by manipulating the corresponding object using a touch screen to cause simulated rotation of 
40 the Illustrated virtual knc* the simulation system adjusts the illustrated virtual Speed dial todisplay the value 
of the knob. This is described in a reaction rule as follows. 

"KNOB speed^knob* 
which is called the event part of the reaction rule, while 
"Drive Diair, •speedjdiar. KNOB^VAL);' 
4S is called the acMon part of the reaction rule. The event or trigger part of the reactton rule Is written using a 
syntax which Is unique to the simulation system (I.e., ATN), while the action part is written In the "C" program- 
ming langauge. 

Mora complex reaction rules are possible. For example, referring to Figure 4, the prototype may contain 
a virtual knob and a virtual light selectively displaying one of two illumlnatton levels, e.g.. black and white. In 
50 the example, the light turns white whenever the value of the knob is less than 500. and turns black when the 
value of the knob Is greater than or equal to 500. 

This relationship can be expressed with a pair of reactton rules. A collection of one or more reaction rules 
is called a reaction taWo as depicted in Figure 5. The reaction table deptoled in the figure has two reaction 
rules, with the event part of both reactton rules being two lines long. The first line gives the primary event or 
55 trigger which must occur for this rule to be triggered. This primary event Is the knob turning. The second line 
of this reactton rule is called the condition of this event The condition specifies that this reactton rule should 
only be taken if the value of the knob Is < 500. Condlttons are also written in the "C^ programming language. 

Each of the two reactton rules have the same primary event as triggers. The rules differ only in the con- 
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dttion which must be true for the reaction to take place. 

!n the prototype developmem system, a user enters a reaction table In the form of a state table. A prototype 
development State Table consists of one or more reaction tables. Only one reaction table is active at any ghren 
time. Asimple simulator system State Table consisting of only one reaction table is depicted In Figure 5. 
6 Since the State Table has only one reaction table, the State and Next State columns of the State Table 
are left Wank. When a State Table has more than one reactfon table In it, each reactkwi table must be given a 
name. The name of each reaction table is called a state. When a State Table is executing, only one reactmn 
table within the State Table is active at any given time. 

A State Table thus consfets of one or more states. When a prototype whose behavfor is specified using a 
10 State Table Is running, the prototype simulatfon system will be in one of the states gwen in the State Table. 
Thus, the word etate is synonymous with "mode*. 

A prototype may be controlled by more than one State Table. For example, different virtual objects may 
be controlled by separate State Tables. 

Each reaction rule can specify that a change in state should occur as part of the reaction to the rule being 
IS triggered. This change In state occurs in response to an Event and satfefactton of the conespondlng Condition. 
When the event occurs, the prototype executes any acttons specified in the actton column In the rule. After 
the action has executed, the state of the State Table changes. Once the state of the State Table has dianged, 
only the reaction rules specified for that new state are active. 

Figure 6 depicts a simple prototype and State Table having two states. The two states are called LOW 
20 and HIGH. When the State Table is in the LOW state, the value of the knob is copied to the dial. When the 
State Table Is In the HIGH state, the value of the knob is doubled and copied into the dial. Flipping the GEAR 
switch toggles the State Table from the LOW to the HIGH state and back again. 

Each of the two reaction tables shown in Figure 6 has two reaction rules. The first reaction rule In the 
LOW slate specifies an actkm in response to the user turning the knob. Since turning the knob does not 
25 change the basic mode of the Prototype, no mode change is required. Therefore, the NEXT STATE column Is 
left empty. 

The second reaction rule is also part of the LOW state. It specif ies that whenever the switch is set to HIGH 
the State Table switches to the HIGH state. The dial is also reset to twice the value of the knob. 

The HIGH state Is structured similarly to the LOW state, except that in the HIGH state, twice the value 
30 of the knob is sent to. and displayed on, the dial. As also defined in the HIGH state, the prototype simulatton 
reverts back to the LOW state when the switch is switched back to LOW. 

Another term used to refer to reaction rules is transitions. 

The reaction rules described above all had events which were triggered by Virtual Input Objects, Other 
reactk>n triggers are possible. Reactton triggers can have one of the following sources: 
35 1 . An input virtual object generating events; 

2 - Clicking the mouse on the screen in an area unoccupied by a virtual object; 

3 - Events generated by Computer Programs; 

4 - Input from a Serial device of connmunlcattons line; 

5 - Time based events; 

40 6 - Variables crossing thresholds; and 

7 - Inputs from real devices which are mapped to virtual objects. 

Other reaction triggers are shown In the table of Figure 7, The first group of events are examples of object 
evanto, i.e. events v^ich are generated by using the mouse with virtual objects in the prototype. Some virtual 
objects have more than one input event associated therewith. Locators {e.g. . mouse or joystick) have three 

46 different Input events. The LOCATOR^DOWN and the LOCATOR_RELEASE event occur upon pressing and 
releasing the mouse in the active area of the Locator. The L0CAT0R.DRA6 event occurs when the location 
of the Locator is changed using the graphic input device on the active "touch' area of the display screen within 
the defined area of motton for the Locator. 

Field events occur when the user types date into an input field, for which a •Read_Fleld()*' function has 

so been invoked. A RELD VALID event occurs If the value typed in is valid with respect to the syntax for the f leW. 
A FIELD INVALID event occurs If the value entered is not valid. In either situation, a RELD event (wShout the 
VALID or INVALID qualification) is generated. 

Referring to the Other Mouse Input Events entry, a NODEVICE event occurs if the user clicks somewhere 
in the prototype that is not within an active area of a virtual objecL This event is received only if it is enabled 

55 in the Runtime Environment using the 'Enable No Device Event" field in the Operational Settings of the 
Configuration menu. 

The ANYEVENT t rigger, responds to any event that occurs from Input virtual objects, as well as any PER- 
IODIC event which occurs. This is useful to detect and tog stray events. 
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The next five events are generated internany within FSM in response to state transitions. The nRST_TIME 
event occurs the first time that a gVen state is entered. This event does not occur a second time If the state 
is entered and exited and entered again. The FIRST.TIME event is often used to perform initial loading of a 
frame, wherein a frame is a collection of objects. 

The INITIALLY event occurs each time that the a new state is entered from another state. This event is 
used to configure the display for the newly activated state. This may Include the loading frames or changing 
the values of variables used by other transitions within that state. In contrast, the FIRST^TIME event is used 
to load the frame with the virtual objects only the first time the State Table is initially entered. Thus, the next 
transhtan has an INITIALLY trigger. In the previous examine, whenever this transition is entered from another 
state, the dial is reset to the value of the knob. The dial is also set to the value of the knob each time a new 
input* value is received from the knob. When the user toggles the gear switch to HIGH, the mode is switched 
to HIGH. There is no action associated with this state. Instead, the system has only associated a change in 
state with this reaction rule. Once in the HIGH mode, the INITIALLY reaction Is performed. This causes the 
dial to be set to twice the value of the knob. 

The use of the INITIALLY event helps make the Slate Table dearer and easier to understand. Compare 
the State Table shown In Figure 8 with that shown in Figure 9. In the State Table of Figure 8. it was necessary 
to place an action In the transition to cause the state to change when switching from one mode to another. 
Although this resulted In the desired behavior, tt is conceptually Incorrect since all the uses of the action rou- 
tine to set the value of the dial to twice the value of the knob should be encapsulated within the HIGH state. 

The IMMEDIATE event is invoked each time that a state te entered, as well as after each reaction in which 
the slate did not change. An application of the IMMEDIATE event Is to perform data logging. 

Referring to Figure 10. different tranaittens are taken in response to different input events. In all cases of 
a transition being taken, a log entry is made. Another use of the IMMEDIATE event Is when there is an output 
virtual object In the display which can be affected by one of many Input virtual objects. In these cases, rather 
than driving the output virtual object from within, transition routines can be factored out whkii drive the output 
virtual object, and place ft in the IMMEDIATE action. An example of such a use of this event is depicted in 
Figure 11. 

Referring to Figure 11. the prototype includes two knobs. The prt^totype displays the sum of the values 
represented by the two kinds on the dial. This is accomplished by storing the value of the knob in the reactions 
30 which respond to the knobs being turned, and driving the dial with the sum of the values in the IMMEDIATE 

event response. ^^a-ti- mih j • ^ »k 

The FINAL event occurs when leaving a state. It occurs only if there is a NEXT.STATE filled in. and tr» 
NEXT.STATE is different from the current state. In this case, the action associated with the FINAL event 
executed before the transllton to the next state. A typtaal use of the RNAL state is to undo any acttons per- 
36 formed in response to the INITIALLY event upon entering the state. Atypical example is unloading of frames 
which were relevant only within that state being left 

The Pseudo Event COMMENT, has no operattonal effect. The remainder of the line is treated as a com- 
ment and Ignored. Comments can also be entered as "C" language comments, le. between /• and For ex- 
ample: 

40 h This is a comment ♦/ - „ ^ ■kK»iAni/«> tk- 

The prototype design system also provides two time based events. The first one ts called PERIODIC. Tne 
PERIODIC event occurs repeatedly at the specified frequency. The syntax for this is 

PERIODIC nn HZ . ^ ^ 

where nn is the frequency of the event In HERTZ. The PERIODIC event can be used to increment counters. 
45 or implement samplers which change the display at specified intervals. , ^ 

The dock which generates the PERIODIC event is a global dock. This means that the PERIODIC dock 
is not reinitialized upon entering a state. 

The other time based event is the ON TIMEOUT event The syntax fbr this is: 
ON TIMEOUT nnSECS 

50 In this notelton, nn must be a posithre Integer This event occurs nn seconds after entry of the stete and is 
used, for example, to detect If the user has teiled to timely enter date or to determine if the user has fmished 
entering date. The 0N_T1ME0UT is reset upon occurrence of a reaction or stete change. 

In addition, there are two user defined evente. The first user defined event Is called USER which is gen- 
erated by a user program. The USER event takes two parameters; the name of the USER event and the value 
55 of the event 

The syntax for using USER generated events is: 
USER User EvenLName 'User.Eveirt.Valus'. 
The USER event is generated within another ATN using the routine Gcnerate.User.Event The syntex is: 
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Generate User Event(-User Event.Naine\"User_Evont_Valuel; 
User generated ewnts are used where multiple State Tables are concurientty executing. These State Ta- 
bles can signal each other using customized events. zm..^ 
As described above, the prototype development system consists of four main components. The Object 
Editor (OE) allows the user to draw virtual objects by specifying the shape, color, placement and texture of 
the graphical objects and ascribe to each an appropriate dass of behavior. For example, if a dial is drawn, it 
can have any shape, or color. 

The Integration Editor (IE) aOows the user to specify the names of data variables which control the shape 
of virtual objects. For example. If a virtual object fe a dial, a particular variable can be made to control the 
10 angle of the 'needle/pointer* on the dial. 

The third component is the State Table Editor. This component allows the user to speafy more complex 
behavior than possible using the Integration Editor of the previous systems. For example, in the Logic Editor 
(LE) the user can arrange to have virtual objects appear or disappear when a particuiar button is pressed 
and a particular conditbn Is outstanding. The State Table Editor fristead uses State Transition Programs, aug- 
mented with 'C" programming code. The State Table Editor replaces the LE of previous simulator systems. 

The fundamental difference between the State Table Editor and the LE is ease of use. The State Table 
Editor significantly reduces the user generated and supplied programming code required to specify the be- 
havioral specif icat Ion for a simulator prototype. 

Thef inal component of the simulator Is the Runtime Environment (RE). The RE integrates the Information 
entered using OE. IE and State Table Editor and runs the specified interactive graphical display. 

The are four phases to using the Stete Table Editor are shown In the flow chart of Figure 1 . When invoking 
the State Table Editor, the user initially sets up the environment of the prototype development system. Once 
the user has set up the enviionment, the State Table Editor can be used. The prototype devetopment system 
records how ttie user set up the environment the last time the State Table Editor was used. 
The following is a description of setting up the environment and editing the State Table. 
The State Table Editor consists of the fbllowing components: 

1. The State Table Spreadsheet; 

2. Displayed Collection of Graph toal Objects called a Frame; 

3. Command Menu Bar 

30 4. Text Entry Window; and 

5 A Displayed List of Choices that are relevant to the current mode. 

A typical State Table Editor environment is shown in Figure 13. The Stete Table includes a menu bar 30 
describing options available in the Stete Table Editor. A Frame Display 32 graphically depicts virtual objwts 
to be defined by the Stete Table Editor. Relevant Choices List 34 provides user selectable commands. Text 
35 Entry Window 36 allows the user to enter virtual object labels and ATN instructions. The resultant system def- 
initions are displayed in Stete Table 38. 

By editing a Stete Table, a user specifies the behavior of a particular graphical display, i.e., a Simulator 
Picture Frame. This Is a frame created using the OE. This frame contems one or more graphic objects. The 
user selects one such frame to be controlled by the Stete Table using the Stete Table Editor. 
40 The user also designates whether a new Stete Table is to be aeated or if an existing Stete Table is to be 
edited In the latter case, an existing Stete Table is retrieved and loaded Into memory for editing. Dunng the 
editing, the user may toad a different Stete TaWe. or a different frame. The other components of the emnron- 
ment are placed in the environment by the Stete Table Editor without user intervention. 

Loading a frame or a preexisting State Tabte is accomplished by choosing the appropriate emry from the 
45 pull down menus In the menu bar. and choosing the desired fite name. 

Once the user has set up the Stete Table environment the Stete Table can be edited. Editing the ^e 
Table includes filling in the cells of the Stete Table. Referring to Figure 13. the Stete Table is organi^d like a 
four column spieadsheeL The State Table can have as many rows as required to specify the desired behavior. 
Each cell In the State Table contains information specific to that cell. 
50 Forexample,lfaparticularcellintheeventcolumnhasaslte-6ubjecraparticularknob,thenlher^^^^^ 

list for that cell Includes the various evente that can be generated by the knob. This may *he e>^^^ 
-MOUSE UP" •MOUSE^DOWN-, -KNOB.NEW.VALUE", -KNOB^HAS.MIN.VAL', -KNOB.HAS.MAXJVAL . 
The cellsin the stete column and the next state column oonteln the names of states as previously designated 

55 ^ T^eSevant list for the stete column is the list of all the states in the Stete Table. This Includes any stete 
which Is already defined by another cell in the state or next state column. 

The relevant list for the next stete column indudes all the states entered in the stete table. In addition, 
certain keywords are also listed including "EXIT". -SUSPEND". 'RESUME" and "RETURN". 
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Both the cells in the Event colunrtn and the Action column can refef to a virtual object as their ■subjecf. 
Relating a ceO to an object Is perfomied by clicking on an event or action ceD, and then clicking on a virtual 
object in the frame. The relevant list for a cell in the Event cdunui depends on the virtual object referred to in 
the ceO. 

If no virtual object is associated with a ceil, then a list of events (hat do not require a virtual object is dis» 
played. This includes events such as "STATE TABLE^STARTED', •STATE_ENrrERED", and 
"STATE_EXITED*. If a virtual object is associated with the cell, the relevant list then includes events that can 
be generated by the virtual object For example, if a part icular cell in the event column has an associated virtual 
object comprising knob, then the relevant list fer that cell includes the various events that can be generated 
by the knob. This may include the events •MOUSE^UP". "MOUSE.DOWN". -KNOB.NEW.VALUE". 
•T<NOB^HAS^MIN_VAL-, -KNOB.HAS.MAX.VAL". 

The relevant list for a c^l in the Action column depends on the virtual object which is referred to in the 
ceil. If no virtual object is associated with the cell, t hen actions thai do not require a virtual object are included 
in the relevant list. This includes actions such as XHANGE.STATE TABLE^PRIORITV, 
-START_COMMUNICATIONS*. and TERMINATE^PROGRAM". 

If a virtual object is associated with the cell, then the relevant 11^ comprises a list of actions which can be 
performed on the virtual object For example, if a particular cell in the actton column has as its associated 
virtual object a particular n^ti^tate light virtual object then the relevant list for that cell includes various ac- 
tions that can be performed on the specified virtual object type. This may include the actions 
•CHANGE^STATE". -CHANGEJTO.DEFAULT.STATE-, -HIDE-, -REVEAL', "BLINK-. 

The list of events and act tons which are associated ¥vilh each object type Is defined by a user alterable 
dicttonary induding a list of events and actions supported by each object type. This altows the set of virtual 
object classes to grow, or the list of events and ad tons which virtual objects support to change, withoiit chang- 
ing the state table program source code. 

Once an event or actton is chosen, the event may be assigned one or more parameters. If a parameter is 
to be assigned, an addittonal window pops up and to altow the user to enter values for the parameters. Typtoal 
parameters property sheets are depicted in Figures 14 and 15. 

Each f told in the property sheet has a 'eet of allowed values". Some fields may receive numeric values, 
while other receive a name of a state of the virtual object and others require the user to choose from a par- 
ticular list of values. When the user dicks on a particular field In the property ^eet a paiameter value window 
pops up. i.e.. is displayed. This parameter value window allows the user to enter the value for the particular 
paiameter. If the paiameter has a fixed set of allowed values, a list of those values is shown. The user then 
dicks on the desired value. 

The list of allowed values nnay come from one of two sources. It may come from the virtual object which 
is the subject of the cell being edited. For example, if the virtual object is a multi-state light, the names of the 
states of the light may be shown. Alternatively, the f ieW may be defined as a "C" or other computer language 
type. If the field type is an enumerated type. te.. limited to a predefined set of values, the list of allowed values 
is taken from the enumerated list for that type. For example, if the type of the field Is ANCHORJYPE and 
the type was defined as: 

typedef enum 

{ RELAT I VE_TO_CRT , REIiATIVB_TO_FRAME , ABSOLUTE , 
SCALED_TO_FRAME } 
ANCHOR_TYPE; 

then the appropriate values are used for that field. 

Finally, if the field is numeric or an art)itrary string, then a text entry field is used. Examples of parameter 
value windows are depicted in Figure 16. 

The basic sequence of completing or filling in a State Table is to select a cell by clicking on it and either 
typing In a value using the edit text window or dicking on the approprteis items from other windows and menus. 
This process is depicted in the flow diagram of Figure 17. 

Initially, the user selects a cell and the system configures the State Table Editor for the selected cell. De- 
tails of the system table configuration routine are shown in Figures 18-20. 

Referring to F^ure 18. the Stale Table Editor first removes any preexisting windows from the display. If 
the selected cell Is a State cell, then a list of slate cell keywords and all known state names are displayed in 
a window. If the cell Is a Next State cell, then a list of next state ceil keywords and all known state names is 
displayed in a window araa. If the celt is an Event ceD, event cell processing is performed in accordance with 
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the flew diagram of Figure 19. 

Referring to Figure 19, if the cell has a subject, then the relevant choice list displayed includes a list of 
events for that virtual object type and the specified cell subject If there Is no subject associated with the Event 
cell, then a list of event corresponding to that type of cell is displayed. A timeout is an example of an event 
not requiring specification of a subject 

The list of relevant choices depends on the dass of the object, the list being different for different object 
classes. Examples of lists of events related to specific object classes are depicted In Figure 21 . One such list 
is needed for each object dass. Similar dasses of objects may have some events of each list In common. The 
lists are stored in a data base. 

If the ceil does not have a subject, then a list of events which require no subject is displayed. An example 
of such a list of events \s shown in Figure 22. 

After t he relevant choices associated with the Event ceD are displayed, a check is performed to determine 
if a relevant choice for the cell has already been selected. If so. the current parameter values are set accordingly 
and displayed in an Event parameters window. 

If the cefl is not an Event ceO, then the cell is interpreted as an Act ion cell. Referring to Figure 22, a relevant 
choice window is displayed corresponding to whether a subject is assodated with the Action call. Art Ion cells 
not requiring a subject indude routines contained in a library such as for computlf^ a random number. The 
system further displays a Relevant Action parameters window if a cell has a relevant choice already chosen. 

The list of relevant choice adipns is determined in a way similar to that used to determined relevant 
choices of events. Example of lists of relevant actions for different objed dasses are depicted In Rgure 23. 

If an action cell does not have a subject, then a list of actions which require not subject is displayed, as 
shown by example in Figure 24. 

Referring again to Rgure 17. once configured, the system waits for an input from a user. The Input is das- 
sif ied into sU types: the user (i) types text into an edit window, (iq picks an edit command from a window, (ili) 
chooses a virtual object from a frame, (iv) selects an item from a relevant choice window, <v) selects a para- 
meter form a window, or {vi) selects a parameter value from a parameter value window. If the user enters text, 
the system waits until the user finishes typing and supplies the text to the prototype development system for 
parsing and further processing. 

If the user designates an Edit command, the State Table Editor performs the chosen editing function. Se- 
lection of a virtual object causes the State Tabte Editor to make the selected virtual object the subject of the 
ceil. 

If the user selects a relevant choice from a window, processing proceeds as shown in the flow chart of 
Figure 25. As depicted, the selected choice is assigned to the celL If the choice requires one or nrwre parame- 
ters, processing is performed as shown in the flow chart of Figure 26 to determine an appropriate default value 
for each required parameter. 

Referring to Figure 26, a check is first performed to determine if the relevant chotee provides a default 
value. If not, then. If the type of chotoe is a characteristic of the virtual objed which is the subject of the current 
cell, then a default parameter is provided corresponding to the spedf icatton of the virtual object Alternatively, 
if the relevant choice is not a charaderistic of the virtual object then a default value is supplied based on the 
type of choice selected. 

Referring again to Figure 17, if the event or action window is up and the user seleds a parameter from 
the parameter window, processing continues as shown in Figure 27 to allow the user to select a parameter to 
be spedf ied. The chosen parameter is then made the current value. Alternatively, if the parameter value list 
window is up and the user seleds a paiameter. processing continues to allow the user to choose a parameter 
value as depided In Figure 28. 

The fdlowing description is an exampleof using the State Table Editor and prototype development system 
according to the invention. 

The user first enters the Objed Editor by typing 'object^editor* from the command prompt or by dicking 
on a command icon at a computer work station. Then, the user defines or retrieves a previously stored proto- 
type, in this example, the prototype is the simplified contrd pand 20 for a train as shown in Figure 29. 

As described and defined using the Object Editor and Integration Editor, the prototype has two output vir- 
tual objeds and two input virtual objects. The two output virtual objerts are traff fc light 22 and speedometer 
24. The input virtual objeds are push button 26 and a gas pedal represented by potentkimeter 28. 

For example, suppose that the operator determines that the control panel is to exhibit the fdlowing be- 
havior. The main contrd is to be the speed control, i.e.. sliding potentfometer 28. The train can travel at any 
speed from 0 to 200 miles per hour. Control panel 20 indudes traffic light 22 which informs the operator of 
the maximum allowed train speed. If traff ic light 22 is green, then the train may proceed at any speed. However, 
as indicated by the crosshatohed area on the speedometer, speeds greater than 180 mph are dangerous and 
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should not be used except under special circumstances. 

When traffic light 22 is yellow, the train may not travel faster than 20 mph. When traffic light 22 Is red. 
the train should stop. 

In the prototype, traffic light 22 should be controlled by push button 28. Repeated pressing of push button 
5 26 causes the traffic light sequence through the cotors red, green and yeOow. Initially the traffic light is red. 
Pressing button 26 once nr^akes it turn to green. Pressing it again maWes the light change to yeflow. Pressing 
it again maizes the light change to red. 

After defining the desired operating rules, the user creates a State Table to Implement these rules. The 
user creates an empty State Table using a main puDdown menu to select "State Table." This causes a display 
10 of a pulldown menu from which the user selects the 'New State Table." 

Next, the user brings up the Pick By Name window. Form the main pulldown menu, the user selects "Util- 
ities'' and, from the resultant puOdown menu, selects "Pick By Name". Then, from the State Table definition 
main pulldown menu, the user dicks on "Utilities'. From the Utilities menu, the user clicks on "Focus Selec- 
tion". From Focus Selection, the user dicks on the second entry in the menu, connecting the Pick By Name 
15 menu to the frame whteh the user has loaded into a Show window for display. Then, the Focus Selection win- 
dow Is removed by dicking on an appropriate fiekl of the Focus Selection window. The user can then begin 
to enter the desired prototype behavior into the State Table. 

The user must first arrange to have the Frame loaded when the prototype begins operatton. This Is ac- 
complished by dfeking on the first cell in the column of the State Table Editor labelled EVENT. IN response, 
20 a window titled "Reievant Chotees" is displayed. From this window the user selects the entry -nRST^TlME". 
The sdeded cell in the ^ate Table Editor now contains the t&xt FIRST.TIME. 

The user next dicks on the first cell In the column labelled Action. In response, the "Relevant Choices" 
window changes to display context appropriate choices. In the "Pick By Name" Window, the user dicks on the 
top element, whteh Is the f ranw Itself. The "Relevant Choices" window now displays new chotoes applk:able 
25 to the f ranne. 

TTie user next selects the entry "Get^Frante" from the Pick By Name window. As a result, a window titled: 
"Arguments of Function: Get^FrameO* appears. This window altows the user to change the parameters to 
the 6et_FrameO action. Since the default parameters are appropriate, no change is required. 

Thef Irst state to be created Is titled RED. The user initially clicks on the first cell in the column labelled 
30 Next StalB, highlighting the display of the cell. As before, a Relevant Choices window wiU appear. The user 
clicks on the cell again causing a data entry window to appear. This follows the general rule in the State Table 
Editor that a second dick on a cell causes a data entry window to be displayed, altowing the user to manually 
input values using alphanumeric keyboard entry. 

The user then types "RED" Into the table followed by a carriage return from the keyboard. The value RED 
35 then appears in the NEXT STATE CeD. Above the State Table editor work area are State Table editing com- 
mands. The user dicks on the command "Append Transiiten" to add a second empty row to the State Table. 

Next, the user dkdcs on the second cell In the column labelled State. From the Relevant Choices menu, 
the user selects "RED" to create the stote RED. 

In the state RED, the user first sets the dial representing the speedometer to 0. To do this, the user did(8 
40 on the second cell in the EVENT column. From the relevant choices menu, the user selects the INITIALLY 
item. The initial behavior of the system in response to entry into the RED state is then specified In the Action 
column. 

To specify the behavtor, the user dfcks on the second cell In the ACTION column. From the Plck_By_Name 
window, the user dteks on and highlights DIAL This causes the dial to be made the subject of the cell. 
45 Fromthe Relevant Choices nnenu,thBuser next clfcks on the Drive_Dial entry whereby window Arguments 
To Function: Drhre_Dlal are displayed. Since ail the default values are appropriate, no change Is made. 

The user again dteks on the Action cell causing a date entry window to be displayed. The user adds a 
second blank line and selects the traffic lightf rom the Pick By Name window. From the relevant choices menu, 
the user selects "Drive.Llght". Since the default value given is the RED mode of the light, no change is required. 
50 The user must next describe the behavkv while in the RED State. The behavtor in the RED state is to go 
to the GREEN state when push button 26 is operated or "dlcked". No response Is required when the user 
changes the speed using the potentiometer In the RED stete. 

To describe the behavior that should occur In response to button 26 being dicked in the RED stete, another 
transition must be added. The user first dicks on the command "Append Transition". Since this transition is 
55 a continuation of the descriptton of the behavior of the RED stete, the user need not fill in the STATE name 
column. 

The user then didcs on the EVENT column of the new transition which is the third cell In the cotumn. From 
the Pick By Name window, the user dicks on the "Desired Speed Button." Attemath^ely, the user can dk^k on 
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the picture of the button, using the left button on the mouse. 

Next, f ran the Relevant Choices menu, the user picks the BUTTON selectton resulting in display of default 
event parameters. Since, in the example, all the default values are correct, no change is required. 

Having defined the RED slate, the user next defines the GREEN state. To do this, the user cficks on the 
NEXT_STATE cell of the transition. Clicking on the cefl a second time causes a data entry window to be dis- 
played. The user defines the name of the state by typing 'GREEN". 

Next, the userfills In the GREEN State parameters to define the behavior for the GREEN state. First, the 
user creates the GREEN state by dicking on the 'Append Transition" command. Since, three transitions are 
need In the GREEN state, the user dicks on the 'Append Transition" command two more limes, for a total of 
10 three times. 

The user next d Icks on t he STATE cell of the f irst of the three transitions that have Just been added. From 
the Relevant Choices Menu, the user dicks on GREEN. Now, the user dicks on the EVENT ceil of that tran- 
sitton. From the Relevant Choices menu, the user defines the initial state by dk*ing on INITIALLY. 

The Initial behavior in the GREEN state is almost identical to the required behavior for t he INITIALLY event 
IS of the Red state. Therefore, the quickest way to enter this action is to copy it from the RED state, and then 
change the details. To do this, the user first dkdcs on the action cell of the INITIALLY transition in the RED 
state. The user then dicks on the COPY CELL command. Next, the user dicks on the actfon cefl of the first 
transitton of the state and then dicks on the PASTE CELL command. 

Next, the user dicks on the first row of the action cell causing a Function Parameters: Drive.DlalO win- 
20 dow to be displayed. The user dicks on the second field in this window. From the new pop-up window dis- 
played, the user selects the POTEN.VAL entry. 

The user now dicks on the second row of this celL The Function Parameters: Drhfe^UghtQ window is 
displayed In response. The user dteks on the second field In this window. This brings up a window with a list 
of modes relevant to the light In the present example, the light can be In the "RED". "GREEN" or "YELLOW" 
25 modes, these modes therefore being displayed in the window. The dfeks on the "GREEN" entry thereby en- 
tering "GREEN" value as the Drlve^Ught parameter. Alternatively, the user can dick twice on the second field. 
In this case, a data entry window will be displayed into whteh the user can type the value "GREEN". 

The nexttask m defining the operation of the prototype is to define the correct response to the user dicking 
on the button, or sliding the potentiometer. To do this, the user dicks on the second cell in the EVENT column 
30 of the transltton. From the Ptek By Name window, the user dteks on the potenttometer Desired Speed. Now, 
from the Relevant Choices menu, the user dicks on POTEN. Next, the user fills in the appropriate response 
to a change in value of the potentiometer. 

To define the appropriate response to edjustment of the potenttometer. the user dicks on the Action cell 
of the transitton- From the Pick By Name window, the user dicks on Traffic_Light. From the relevant choices 
35 window the user dicks on Driva.Dial. The Function Parameters: Drive_LlghtO window is then displayed. 
In this window the user dicks oiTthe second ceil which has displayed therein 2EROJ/AL A pop-up window 
displays available values. The user must then dtekon the POTEN^VAL value. 

To define the YELLOW State, the user first creates three transitions using the Append Transition com- 
mand. The first transitton describes the initial behavior ofthis state. The user first dicks on the STATE column 
40 of the first transitton of the YELLOW state and YELLOW is selected from the relevant choices column. The 
user next dicks on the EVENT column, and selects INITIALLY from the Relevant Choices menu. 

The desired behavior is to limit the speed to no more than 20 mph in the YELLOW state. To do this, the 
user types in a short program whtoh implements the desired behavtor. The progrem can be entered by dicking 
twtee on the Actton cell ofthis transition, causing display of a data entry window. 
45 The program is entered irito the cell as follows: 

Drive_Light ( "Traf f ic^Light" , •Yellow" ) ; 
float desired_speed; 
» desired_speed = potek^VAL? 

if {desired_speed > 20.0) desired_speed = 20.0; 
Drive_Dial( **Speedoinerer " , desired_speed) ; 

56 

Next, the user defines the response to the operator attempting to change the speed of the train. The user 
clicks on the EVENT cell of the second transition of the YELLOW state and selects the Pick-By-Name window 
select the Speed control. 
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The desired action for this cell Is the same as for the INITIALLY action. To copy the action, the user dicks 
on the ACTION cell of the INmALLY tranrftion of the state, dicks on the command COPY CELL, and then 
clicks on the empty action cell below. To fill in the empty cell, the user dicks on the PASTE CELL command, 
causing the code to be pasted into the Actkincen. 

Finally the user must describe the behavky if the user dicks on the change Jight button while in the YEL- 
LOW stale! To do this, the user dicks on the last cell in the EVErfT column. From the Pid^-By-Name window, 
the u^r didffi on the Change.L^ht window. From the relevant choices window, the user then dicks on the 
BUTTON event Next, the user clicks on the last cell in the NEXT_STATE column. From the relevant choices 
menu, the user selects RED by dicking on the displayed term. 

This completes fining in the Stale Table, shown in completed form in Figure 30. 

The user must next save and compile the State Table, First, the user dicks on the State Table Editor main 
pulldown menu. From this menu, the user selects the Logic Prototyping entry. This cause display of a flow 
chart like Ijogic Prototyping Control Panel. 

In the Logic Prototyping window, the user should dick on the command SAVE. This instructs the Slate 
TaWe Editor to save the Slate Table just entered into the warehouse. The user must give the State Table Editor 
a name by typing in TRAIN", into t he vwndow which comes up. followed by pressing the <entBr> key. The Stale 

Table is then saved. . - f>_^ ♦ 

To compile the State Table, the user must dick on the COMPILE ATN command In the Logic Prototyping 
window. FlnaUy, when the MAKE TASKS command in the Logk: Prototyping window is highlighted, the user 
should dick on the highlighted command. This completes the behavioral part of the prototype. 

TTie final step Is to run the State TaWe Just created. To do this, the user invokes the Runtime component 
of the prototype development system. This is done by selecting the Session command in the main State Table 
Editor pulldown window. Next, the user dicks on the command Run Time Environment. Initialing the Run 
Time components of the prototype development system. 

Using standard simulation system procedures, the user selects the warehouse where the complied State 
Table is located. From the Storage Contents window, the user first selects the file TRAIN, with a file type of 
ATN loads, and runs the file causing the prototype to begin executton. The user operates and interacts with 
the prototype by, forexample. changing t he values of the speed control and pressing the button while watehing 
the results on the speedometer and the traffic light 

As demonstrated, the process of creating a State Table Is relath^ely simple. Most of the required Informa- 
tion in a State Table can be entered with mouse didcs. When the default parameters that are entered Into the 
State Table are not correct, the entries can be easily changed. When necessary, the user can dick twtee on 
any field, and manually type in or edit the dess-ed text 

In summary, the prototype development system according to the Inventton provides a system and method 
for defining the responses and steles of a simulated system using a series of context sensitive menus to gen- 
erate state teWes. The Infdrmatton from the stete tebles Is used to generate program code used by the proto- 
type development platform or a teigel platform to simulate a desired system. 

Although the present Invention has been described and illustrated in deteil. it Is dearly understood that 
the same is by way of illustralton and example only and is not to be taken by way of limitellon, the spirit and 
scope of the present inventton being limited only by the terms of the appended daims. For example, although 
the State Table Editor has been described in the context of a system for simulating a physical system, the in- 
ventton is alsoappltoable Id other systems such as real-time control, artif teial Intelligence, and other date proc 
essing systems the operation of which can be defined by a state transition table. 



Claims 

1. A real-time finite elate prototype devetopment and simulator system for graphically responding to user 
Inpute by displaying virtual o^ds forming a modeled system on a monitor, comprising: 

a graphic Input devtee responsive to said user inputs for deriving a posllfanal signal; and 
a processor unit induding: ux * 

(i) an Input module responshre to said poslltenal signal and to a position of one of the virtual objecte 
for deriving selection data. * . . u--.-*- 

(H) an object editor module responsive to said selection date for defining ones of said virtual objecte 
as Input and output virtual objects and ascribing to each a class of behavfar. 
(iii) a state table editor module responsive to said selection date and to said class of behavior ascribed 
to said virtual objects for defining a table of parameters describing the modeled system induding: 
(a) system states, 

16 



EP0 597 316 A2 



(b) events tD be monitored, 

(c) actions to be taken in response to the monitored events, and 

(d) next states to be entered by said nnxleled systent in response to the monitored events, and 
(iv) an execution module for detecting events and, responsive lo said table of parameters and to said 
detected events, for selectively displaying and manipulating said virtual objects on the monitor. 

The system according to claim 1 wherein state taWe editor module includes an interpreter module respon- 
sive to said table of parameters for supplying command data In the form of an Augmented Transition Net- 
work CATN) Language. 

The system aooording to claim 1 wherein saM state table editor module Includes a collectton of reaction 
rules forming a reaction table stored in menwry. 

A finite state machine for slmuJat'ing a system and responsive to a signal representing a present state of 
the simulated system and to a plurality of input signals for deriving an output signal including a signal de- 
fining a next state of the simulated system, said finfte state madiine including: 

a random access memory responsive to an address signal for selectively retrieving instruction sig- 
nals stored therein; and 

a processing unit for storing the present simulated system state and responsive to said simulated 
system slata, the plurality of input signals and saM retrieved instructbn signal for supplying saM address 
signal and defining the next state of the simulated system, saki processing unit including 

(i) a state table editor module responsh^e to a user input signal for deriving a stato table defining 

(a) present states of the simulated system. 

(b) input signals to be monitored by the simulated system. 

(c) actions to be taken by the simulated system in response to the monitored signals, and 

(iv) next states of the simulated system to be entered in response to the nrtonitored signals, and 

(ii) a runtime environment module responsive to sakI state table for toading said instructton signals 
into said random access memory. 

A method of real-time finite state simulatfon for graphically responding to user inputs by displaying virtual 
objects on a monitor, comprising the steps of: 

deriving a positional signal representing a position of a cursor on the monitor in response the user 

inputs; 

supplying selection data in response to (i) the positional signal representing the position of sakI 
cursor oorresponding to Oi) a positkin of a virtual object on saki monitor. 

defining virtual input and output type objects and associating wKh each a dass of behavtor respon- 
shfe to sakl selectton data: 

defining a state table in response to said selection data including: 
(i) stetes of a simulated system including the objects, 
(fl) simulated events to be monitored, 

(Bt) simulated actions to be taken by the simulated system in response to the nwnitored events, and 
(iv) next stetes of the sintuteted system to be entered in response to the monitored events; and 
seteothraly displaying and maniputeting said virtual objects in response to said state table, sakl 
selection date, other virtual objects and contents of variables. 

The method of claim 5 further comprising the step of associating with ones of saM virtoal objects respec- 
tive names of variables to which said associated class of behavior of said virtual objects are respectively 
responsive; 

A method of prototype development and prototype simulatton, comprising the steps of: 
defining graphic objects for display on a monitor, 

associating with each of the graphic objects enumerated inputs to which each graphic object is 
responshre and a response of each graphic object to the respecth/e enumerated inputs; 

displaying a state table having plural rows and columns on the monitor; 

receiving a graphic device input signal and. in response, poslttoning and displaying a cursor on the 
monitor; 

detecting a position of saM cursor corresponding to a posltton of one of sakl graphic objects on 
the monitor; 

displaying a menu of input and responses associated wth sakJ one graphic object; 
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selecting an input and a response from the displayed menu; and 

entering data corresponding to the selected input and re^Kmse in said stats table. 

The method of claim 7 further comprising the step of selecth^ely displaying the graphic objects on the 
monitor in response to input and response data stored in said state table. 

A method of graphically modelling a system, comprising the steps of: 
defining a set of graphic objects and attributing to each 

(i) at least one controlling parameter, 

(ii) a set of one or tnare displayable visual characteristics, and 

(ID) changeable features of said displayable visual characteiistics responshre to said controlling para* 
meter 

describing a state table defining the operation of a finite state machine, the state table Including 
(i) present states of the finite state machine, 
(ti) events to be monitored in each of the present states, 

(Hi) controlling parameters to be generated in response to detection of a respective event to be moni- 
tored in said present states, and 

(iv) next states of the finite state machine in response to detection of a respectwe event to be monitored 
in said present states; 

operating said finite state machine responsive to said state table to display said graphic objects 
including 

(i) defining an instant one of said present states of the finite state machine defined in said state table. 

(ii) detecting an event of the events to be monitored in said instant present state. 

(lii) generating a controlling parameter in response to said detected event of sakJ Instant present state 
In accordance with said state table, and 

(tv) defining a next state of the finite state machine in response to said detected event of said instant 
present state in accordance with said state table; and 

displaying said graphic objects in response to said oontnlting parameter generated by said gen- 
erating step. 

A system for developing and executing interactive visual applications wherein dynamic date is mapped 
into coherently animated virtual objects and operator interaction facilities am provided to interact with 
the virtual objects, the system comprising: 

a central processing unit responsh^e to operator control signals for supplying address and control 
signals; 

random access memory providing Instructions to said central processing unit In response said ad- 
dress signals from said central processing unit; 

a non-volatile storage medium for supplying said instructions to said random access iremory in 
response to said control signals from said central processing unit; 

a graphics display device responsive to said control signals from said central processing unit for 
displaying the virtual objecte; and 

operator Input nwans for supplying said operator control signals to said central processing unit, 
said operator control signal including positional and alphanumeric signals, said operator input means in- 
cluding 

(I) a locator/trigger device for providing said positional signals to the central processing unit, and 
(Ii) a data entry device for supplying said alphanumeric signals to said central processing unit; 

said instructions including functional modules for defining operations of said central processing 
unit, including 

(!) an object editor module responsive to said operator control signals for defining the virtual objects 
by relating a graphical appearance of said virtual objects to a behavior of said objects during execution 
by the system; 

(ii) an Integration editor module responsive to said operator control signals for mapping ones of the vir- 
tual objects into names of variables, the contents of memory locations of said random access memory 
corresponding to said named variables, said named variables being used for redrawing the virtual ob- 
jects on the graphics display to reflect changes in the contents of the memory locations associated 
with said named variables and said named variaUes further supplying graphical access to data in re- 
sponse to said positional signals from said locatorArigger device and to screen locations of said virtual 
objects. 



18 



EP 0 597 316 A2 



(lii) an execution feciilty for redrawing ones of sakl virtual objects in response to dynamic data stored 
in said random access memory and in response to operator control signals, the execution fedllty fur- 
ther responsive to predetermined logic specification data; 

(iv) saki logic specification data specifying sets of events and corresponding reactions which should 
occur in response to the respective events, an respective origin of the event a state of the system 
wherein said state is a finite stats machine model of the system, and predetermined condftlons, wherein 
each of said events originating from one of (A) ones of said virtual objects, (B) a system dock signal. 
(C) control signals from said central processing unit, (D) messages from other computer systems, or 
(E) changes In the contents of the named variables; 

(v) said logic specification further specifying the next state that the system should transition to after 
an event is received; 

(vi) said logic spedficatbn further spedfying the reactions that occur under contrd of the logic spec^ 
if Ication, ones of which affect ones of the virtual objects displayed cn the display device; and 

a state table editor responsive to said operator control signals for defining said logic specification 
by spedfying: 

(i) system states; 

(ii) events and conditions to be recognized in respective ones of said states; 

(iii) adions to be taken In response to respective ones of said events and states; and 

(iv) next states to be entered in response to respective ones of sakj events and states. 

1 1 . The system of dai m 10 wherein said logic specification is generated responsive to selection of the virtual 
objects displayed on the graphics display to fill In a state table induding said events and conditk>ns to 
be recognized and corresponding actions to be taken. 

1 2. The system of daim 1 0 induding rrwans fbr spedfying events and respedive sources of said events by 
dicking with the locator/trigger device on the visual representat ion of the virtual object generating respeo- 
tlve ones of said events. 

13. The system of datm 1 2 wherein said state table indudes said logic specification data. 

14. The system of dalm 1 3 including means responshw to said locatonftrigger device ft)r selectively inserting 
said logic spedficatbn data into said state table. 

15. The system of daim 11 induding means responsive to said operator control signals for entering state 
nanrtes of respedive ones of said states Into the state table. 

16. The system of daim 15 wherein said means for entering said state names indudes means for copying 
from one of said cells forming saM state table to another of said cells forming sakI state table. 

17. The system of daim 1 9 wherein said executton facility indudes sakI logic specification and said execution 
ladlity is stored in saki random access memory during a system executk>n mode of operatbn. 

1 8. The system of daim 1 0 in which sakj logic spedf icat ion is stored In a computer controlled setup forming 
a real equivalent of a modeled system, wherein saM conputer controlled setup exhibits a behavior sub- 
stantially the same as a behavior of said modeled system. 



19 



EP 0 597 316 A2 




Ei3 



20 



EP0 597 316 A2 



A 


STATE 


EVENT 


ACTION 


NEXT STATE 


f 






















































Figure 2 




Speed Knob 



[VENT 


ACTION 


m speedjnob 


Dmejiall". "speedJial'KNOBVALh 



Figure 3 



21 



EP0597 316 A2 




S|»tdifin 



SN 

G 

SptedKoob 



EVENT 


ACnOK 


KiiQB spHdtanb 
|KH0B_Vtt<5M| 


; llriRJl|lItr^|lHdJ|r.^^^ 


nnfispttlloNb 

ini)iLYAL>=;oii 





Figure C 



STATE 


EVENT 


ACTION 


NEXT STATE 




OKIB speed ksob 
IKNQB m<W 


!lriifJ5|iH".'^_P', 11; 






. (nnLVA>»wi 


Omtliillttn'speti^t", \\\ 





Figure 5 



22 



EP0597 316A2 





f w 










A It iff* 








SDMdDial J 




HIGH 
LOV 


W 

Speed Kmb 



STATE ! EVENT 


ACTION 


NEXT STATE 


[ KHOBspeedJnob ^ 

r's'wTnTiitar'w 




"m 


HOH ! KNOB spetOnob 


Dmtpiair 'sptedjal' . KNOBJfAL *2|; 




I SWITCH gearlOV' 


' Drivejair "jpeedjW .KHOBVAL ); 


LOV 



Figure 6 



23 



£P0ra7316A2 



X 



» > 



3; 



.52 



§ 

is 

«^ 
O 

s 



.ce \ 



5' 



O 

.1 



J- 



•J 



Eg 



^1 



ig; 



i 



S5 



i t 

s 



i 

x: 

g 



ft 2j 



24 



EP 0 597 316 A2 



STATE 


i EV£MT 


i ACTION 


NEXT STATE 


LOW 


1 WSTJR 


: Gtlffaiitr-toDtf<J|a«lM. 
FffifffiOlDOfRAIf): 






f MIQIinr'Har 




' ^ 1 




: KNOB spHtfanb 








; MTQIity'KM' 


;Ori«t|fair>t|!Jj|-,l3IOOALI; 


LOW 1 



Figure 6 



CONTROLPANEl 





( » 


IIH 










V 


> 




lOH 







STATE 



EVENT 



ACTIOH 



NEXT STATE 



LOW 



■ FfiST TIIC 

Tmmy" 



GiLffiMr'niHMiAKl", 
IflBEGR^^ 



: KNOB^edJiHl 



HDI 



HIGH 



: MIlMiY 



llri»tflarrJ|i«yi".l(liOyfAl*2l: 



LW 



Figure 9 



2S 



EP 0 597 316 A2 



STATE 


EVENT 


ACnOH i NEXT STATE 




FBSTJK 
KNOe spttdjMbJ 


I.RSJlWIllHlAHEl: ■ 

.J??!!!!^lW'y?^".•J?!^ 

OriiLK)ll_|; I 




POTDITlOHnER spfriMi 


. DwyMUl: j 



Figure 10 



CONTROL PANEL 





r 5H tt« I5«i« ^ 
ij^^- ' ^'^^JI^^^ 






^ Spied Do) J 




Q O 

SpKdXmbl SMKnobI 



STATE i EVENT j ACTION i tfXT STATE 





; flRSIJIlE 


i WFwHrMOHiiioiPANa: • 

; I^FOKQUUNDiilMf}; \ 




i MffOIATE 


I Orivejil r "ifHiJi', knti t » faiob 21; [ 






i Imab 1 : KHOBiAL; i 




! KNOB spetdJiMy 


: kmbliKMejAL; i 



Figure 11 



26 



EP 0597 316 A2 





— ^v— 






sertreiMNUBir 








J 



GDirilCSrAIEPMM 



usawwRiooeoAit 



SWCTICSTAIt TABLE 



[ 



1 



J 




STOP 



^ Figure 12 



27 



EP0S97 316 A2 



36 





^i^ 




32. 


1 


2& 



FHe Edit Stitefonn Options Help 



y 



GO 



o o o o 
o o o o 



o 



RELEVANT CHOICES 


CHANGE COLOR 1 




CHANGE UNBSTYIE 




CHANGE TEXTURE 


■ 


HtGHLtGHTOWHtC 




BUNK 


▼ 



Text Entry 



STATE 



TRIGGER 



ACTION 



f<EXT STATE 



Figure 13 



28 



EP 0 597 316 A2 



ACnON PARAMETERS 



Object: UGHT / TrafficUght 
Action: Change Slate 



Name Of State: 



RED UGHT 



Figure 14 



ACTION PARAMETERS 



Ob|ect: XY OBJECT / Car Icon 
Event: Move^Object 



Anchor \ RELATIVE J'O.CHT 



X Coordinare 



0^ 



Y Cooratiate 



0^ 



Figure 15 



Paraineter Value 

Reld Name: NAME.OF.STATE 

Object: UGHT / TRAFFICUGHT 

Type:STATE.NAME 



RED,LIGHT 
GHEEN^UGHT 
YEU-GW^LIGKT 
LEFT_TURN,UGHT 
WAU< UGHT 



Parameter Value 
Held Name: ANCHOR 
Object: XY OBJECT / Car Icon 
Type:ANCHOR_TYPE 



REUTlVEjrO.CRT 

RELATIVEJTO^FRAME 

ABSOLUTE 



SCALED JO^FRAME 



Parameter Value 

Reld Name: X Coordinate Object: XY OBJECT / Car Icon Type: float 



Enter Value (0.0<3.0) 



Figure 16 



29 



EP0 597 316 A2 



USERSaCCTSACSLL 




SYSTEM WAIT RM USCR MRIT 



USCfl TYPES 
WTO 

TBrreoiT 

WINDOW 



USERPCXS 
AN EDIT 
OOUUANO 
FROM THE 

WMOOW 




SYsm/i 

SHOULD 
EXECUTE B3FT 
COMMAND 



USB) 
CHOOSES 
AN OBJECT 
FROM THE 
FRAME 



SYST^ MAKE^ 

SELECTED 

OBJECT 

THE "SUBJECT" 

OF THE CELL 



USEHSSLBCTSA 

•naevANT choice" 

FROM THE 

nOEVANTCHOCE 

WMOOW 



©na^vANT 

CHOCEMOOE 



IF {EV8IT on ACTION) 
PAMUMEIERW 
WMDOWbUP 

AND 



USERSa^CTSA 
-pAqAMETEfT 
FROM THE 
PARAMCTER 
WMOOW 



9 USER 
CHOSE 
PARAMETER 
TOFUL 



IF 

PARAMETER VAUiE 

LisTwmoow 

BUP 
AND 

USER SELECTS 
A PARAMETER 
VALUE FROM 
1HE PARAMETER 
VALUE WINDOW 



^USERCHOSli 
PARAMETER 
VALUE 





Figure 17 



30 



EP 0 597 316 A2 



RBIOVE ANY EXISTINQ WWOOWS 
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Figure 19 
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C PAGE 3 ^ 
COMMerr -llOs it an ACT^{^ 




RafVAKT CHOICE.UST • 
USTjOF.ACTfONS( OBJEGT.TYPSl CBX.SUBJECH): 



POT UP -RBJEVAMT CHOICES -WINDOW 
USING HBfVANr jCHOICE.USr «id CUR«raC«B 




CURRBir PARAM^VAUiES - 
GerjCURRENr.PAHAMJ/Aa)ES( CuiwniC«a. Retev»mChoice<CufTwnC««)): 
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Figure 20 
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BxampleH uf EVENTS Ihr an objecidass: 

Olqect Oaf»i>: KNOD 

KNOB.TUBN£n 

KNOB.MOVBD 

KNOB_PRR88ED 



Object CIbbb: FTEIJ) 

FIELD VAIJD 
FIELD INVALID 
MRU) 



Figure 21 
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Object Clasa: NONE 

NO_DEVJCK 

ANYEVENT 
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INITIALLY 
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FINAL 

COMMENT 

TERIODIC 

TIMEOUT 

USER 



Figure 22 
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ExampleB of ACTIOKS tor an object class: 

Object CIom: UQHT 

1 • w* Dk.nm Utate I* Tlii» changBB tha "aode of l*>e light. •/ 

o£c£S^!B«S.-Color A-S.appliTto.llpyect.wWd^havca 

♦ badtground color. •/ 
Object J40VC /• apP^<» *^ movable objects. •/ 

OWeci Claw: FIELD /* Text fields con be input, output, or botli in and out ^! 

OWect Change Back.Color This applies to all oWecls which have a 
' « bad«round color. */ 

/* This applies to all movable objects. V 
/♦ T^iB appUes to all o^octs thai have t«xt in 
♦ them, •/ , 
P For a t«t fieldt set its default valua •/ 
Set the validaUon rules for the field */ 
/♦Bst the value of a field.*/ 
/* Set the value of the field Ui the dofault 
•value.*/ 



OlJOect^Movc 
Text^ont^Change 

Field.SctJ>efault 
PieldlSet^Validaticin 

Fiell.86t.Value 

FieldLIlc8ioie.I>efault 



Figure 23 



Kxamplesof ACTIONb that apply tone ol^joctdass: 



Olgect Class: NONE 

romom^number 
prinlwdisplay 
sei^cobf^liist 
exit 



r Compute a random number ^/ 

/• Send a copy of the display to the printer */ 

Add names to the cc^or table. V 
/* Btop all processing V . 



Figure 24 
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Figure 26 
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